Field
Embodiments of the present invention generally relate to computer networking. In particular, various embodiments relate to inline inspection of security protocols, including, but not limited to Secure Socket Layer (SSL) and Transport Layer Security (TLS), by directly accessing raw data of a security protocol session by an inspection engine and transmitting the raw data in the same session with or without re-encryption.
Description of the Related Art
Many networking applications require secure and authenticated communications. SSL and its related protocols are often used to enable secure communications between a client and a server. According to SSL protocols, session information between an SSL client and an SSL server are negotiated through a handshake phase. The session information may include a session ID, peer certificates, the cipher specification to be used, the compression algorithm to be used, and shared secrets that are used to generate symmetric cryptographic keys. The SSL client encrypts a premaster secret with a public key from the SSL server's certificate and transmits the premaster secret to the server. Then, both parties compute the master secret locally and derive the session key from it. After the handshake phase, a secure socket is established, and application data encrypted by the session key can be securely transmitted between the client and server.
To inspect data that is encrypted in an SSL packet, a security policy enforcement device may perform SSL man-in-the-middle inspection as shown in FIG. 1. As shown in FIG. 1, a security policy enforcement device comprises a kernel 121, a transparent SSL proxy 122 and an inspection module 123. When SSL client 110 initiates an SSL session with SSL server 130 through network 140, a client hello message is transmitted by SSL client 110 though an SSL port, such as port 443. Transmission Control Protocol (TCP)/IP stack 121 intercepts the client hello message by monitoring the SSL port. Next, the client hello message is redirected to transparent SSL proxy 122. Transparent SSL proxy 122 uses its own certificate to negotiate with SSL client 110 to setup an SSL session 1. On the other hand, transparent SSL proxy 122 sends a client hello message to SSL server 130 and negotiates with SSL server 130 to setup an SSL session 2 over network 150. After the two SSL sessions are established, transparent SSL proxy 122 possesses a session key used for encrypting and decrypting data in SSL session 1 and another session key used for encrypting and decrypting data in SSL session 2. When SSL client 110 transmits data to SSL server 130, data transmitted by SSL client 110 is actually encrypted by the session key negotiated with transparent SSL proxy 122, not SSL server 130. After an encrypted packet that is transmitted from SSL client 110 in SSL session 1 is intercepted by kernel 121, the packet is redirected to transparent SSL proxy 122. Because transparent SSL proxy 122 possesses the session key of SSL session 1, it can decrypt the encrypted packet sent by SSL client 110. After the packet is decrypted, plain data of the packet is sent to inspection module 123 by kernel 121. The plain data is scanned by inspection module 123 according to inspection policies. If the plain data passes the scan, the data is re-encrypted by transparent SSL proxy 122 using a session key that is negotiated between transparent SSL proxy 122 and SSL server 130. A re-encrypted packet is then transmitted by kernel 121 to SSL server 130 through SSL session 2.
Because the SSL proxy uses plain sockets to do the network communication, it can be easily implemented. However, the problem is its poor efficiency. In the above example, transparent SSL proxy 122 is a full-function SSL proxy and is used for establishing the SSL connection and encrypting/decrypting SSL packets. The intrusion inspection module relies on the SSL proxy to decrypt the SSL packet before it can inspect the network traffic in plain text. After the inspection is done, SSL proxy 122 needs to re-encrypt the data and relays to peers. Thus, traffic needs to bounce back and forth between kernel space and user space applications.
Further, sockets are system wide resources and all networking applications in the same device may contend for such resources. The TCP/IP stack has to apply a regular resource management. The socket application programming interface (API) overhead causes further slow down in SSL traffic handling.
In a man-in-the-middle SSL inspection system as shown in FIG. 1, transparent SSL proxy 122 establishes SSL session 1 with SSL client 110 and establishes SSL session 2 with SSL server 130 independently and the two sessions are not matched. As shown in FIG. 1, transparent SSL proxy 122 negotiates with SSL client 110 and cipher suite 1, which is the most secure cipher suite that is supported by both of SSL client 110 and transparent SSL proxy 122, is used in the SSL session 1 between the two peers. Similarly, cipher suite 2 which is the most secure cipher that is supported by both of SSL server 130 and transparent SSL proxy 122 is selected. However, the negotiated cipher suites in the two sessions may not match because SSL client 110 and SSL server 130 may support different SSL suites.
Further, in a man-in-the-middle SSL inspection system as shown in FIG. 1, TCP flow would be altered from the beginning of the proxy involvement. For example, certificate 2 of SSL server 130 is received by transparent SSL proxy 122 in a server hello message sent by SSL server 130. However, transparent SSL proxy 122 sends certificate 1 of its own, instead of certificate 2 of SSL server 130, to SSL client 110. The certificates may have different sizes, for example, certificate 1 may have 1024 bits while certificate 2 may have 2048 bits. After the server hello messages are sent in the two sessions, TCP sequence number 1 in SSL session 1 may be 1024 bits smaller than TCP sequence number 2 in SSL session 2.
The transparent SSL proxy 122 maintains two distinct TCP connections for each SSL session, the TCP/IP stack 121 needs to do extra work to keep the traffic flowing, such as packet retransmission, fragmentation/defragmentation, TCP window scaling, etc.